A service registry and repository registers and stores service descriptions as part of a service-oriented architecture (SOA) promising business agility and resilience through reuse, loose coupling, flexibility, interoperability, integration and governance. These promises are addressed by separating service descriptions from their implementations, and using the service descriptions across the life cycle of the service. Standards-based service metadata artefacts, such as Web Service Definition Language (WSDL), XML schema, policy or Service Component Architecture (SCA) documents, capture the technical details of what a service can do, how it can be invoked, or what it expects other services to do. Semantic annotations and other metadata can be associated with these artefacts to offer insight to potential users of the service on how and when it can be used, and what purposes it serves.
Service descriptions are used by analysts, architects, and developers during a Development Phase of the SOA life cycle to locate services to reuse and to evaluate the impact of changes to service configurations. Service descriptions are used by deployers in a Change and Release Phase and by administrators in a Runtime Integration Phase. It is used in the Operation Phase of the life cycle to support policy enforcement required by Service Level Agreements (SLAs) and to present a more comprehensive view of the managed service environment. Service descriptions are used by various technologies for different purposes and needs to be persisted in a reliable and accessible format. Service descriptions are variously described as metadata, objects, documents, entities and artefacts.
A service registry and repository is an application that persists service descriptions as a data objects in a relational database system. Typically a user uses a graphical tool to design classes that represent the service descriptions that need to be persisted. Java objects, that represent the classes, are compiled into binary files. Database schema are generated that can represent the objects and are installed into a relational database (IBM® DB2®, Oracle etc). The objects are registered with service register and stored within the repository. The objects are persisted and retrieved directly from the object database. IBM and DB2 are registered trademarks or trademarks of International Business Machines Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation.
One type of service registry and repository stores the descriptions as objects within the repository and queries the repository using an object query language. An example of this type of service registry is IBM WebSphere® Registry and Repository (WSRR) uses an IBM object query language called XMeta Query Language (XMQL) for internal communication with the repository. WebSphere is a registered trademark or trademark of International Business Machines Corporation in the United States and/or other countries.
XMeta Query Language (XMQL) is a declarative object query language designed for the efficient retrieval of objects stored in a repository such as WSRR. XMQL allows the use of the dot operator for accessing predefined properties on a given modelled object type. XMQL also allows a dereferencing operator for traversing relationships between any two given object types. The XMQL query expression is defined in the context of a given package registered with WSRR. XMQL has a “SELECT-FROM-WHERE” type of structure and returns a set of objects.
The SELECT-FROM-WHERE clause is the basic structure of an XMQL query. It allows the user to specify which class(es) should be searched to retrieve information, and which parts of the information to be included in the results set. It also allows the user to specify conditions to filter out of the results set the instances that do not meet the conditions.
The SELECT clause defines the structure of the query result, which can be either a collection of objects, or a collection of rows with the selected attribute values. The entries in the select part of a query constitute the so-called projection list of the query, in that they define what is projected out of the repository and into the result set entries (result objects or result rows of atomic values, depending on the number and type of the entries in the projection list). When retrieved, the type of the query result is a List of instances of objects, or a List of arrays (result rows) of instances of objects (result row columns).
The FROM clause introduces the primary class extent against which the query runs. A class extent is the set of all instances of a given class (including instances of its sub-classes). A variable needs to be declared to iterate over the instances of the class being queried, the so-called primary iteration variable. That variable can be used in the other parts of the query and denotes an instance of the class extent being iterated upon. The FROM clause also allows the introduction of other variables to iterate over instances that can be reached through navigation via multiplicity-many references from previously introduced iteration variables. These extra variables are called secondary iteration variables. As explained above, unqualified class names in a query expression are resolved relative to that package, the so called query context package.
The WHERE clause introduces a predicate that filters the instances of the class being queried. This is an optional sub-clause.
The basic SELECT-FROM-WHERE structure can be extended with other optional clauses.
Example 1: SELECT e FROM e in Employee WHERE e.salary>200000. This query returns the instance(s) of class Employee (including any of its sub-classes) whose salary attribute value is greater than 200000. The FROM clause gives the class whose extent the query will filter, class Employee, and introduces the variable ‘e’ to be used to iterate over that class extent. The extent of class Employee includes all instances of all of its direct and indirect sub-classes. The SELECT clause defines the type of the entities returned in the result collection to be instances of class Employee or any of its sub-classes. In this example, the class being queried is an abstract class and the result collection will contain instances of sub-classes FullTimeEmployee and Part TimeEmployee. The WHERE clause filters the instances being iterated upon so that only those for which the value of attribute salary is greater than 200000 are returned in the result.
Example 2. SELECT e FROM e in Employee. This example retrieves all the instances of class Employee. It also illustrates the fact that the WHERE clause is optional.
Example 3. SELECT e FROM e in AnotherPackage::Employee. In this example, the package in the query expression takes precedence over the context package, in case a class with the same name is defined in both. If the class defined in the query context package or if it is defined in a package it depends on and there is no name conflict (i.e. different classes with the same name defined in different packages depended upon), then there is no need to qualify the class name in the query expression.
U.S. Pat. No. 7,028,028 (Enosys Markets Inc.) discloses a system for querying markup language data stored in a relational database according to markup language schema. The system translates from the input XML query language to apply corresponding query instructions to the underlying relational database using a relational database query language such as SQL.
Although a relational database query language is a useful way to access objects in a repository it does not return complex collection of objects as an object query language can. As such, an object query language is a powerful way to access objects in a repository. Furthermore, object query languages provide additional features such as object references and dot notation where SQL does not. However, one problem for users accessing objects in the repository is that a specialized object query language can be counter intuitive if one is used to a different query language such as a path expression query language. For instance XPath is a path expression language that is more suitable for accessing content within an XML instance document than for accessing objects in an object database but many users are familiar with it and prefer to use it to locate objects.